Beschluss: Datenschutz genau definieren
Version: "Nutzungs und Datenschutzziele"
1 | Vor einer Einführung eines Liquid Democracy Tools muss man |
2 | sich Gedanken dazu machen, wie und wofür das Tool genutzt |
3 | werden soll und welche Anforderungen an den Datenschutz sich |
4 | daraus ergeben. |
5 | |
6 | Für den Einsatz eines Liquid Democracy Tools im |
7 | Landesverband Schleswig-Holstein können sich ganz |
8 | unterschiedliche Nutzungsszenarien ergeben. Beispiele sind: |
9 | - Politische Willensbildung |
10 | + Diskussion und Abstimmung von Entwürfen von Antragstexten |
11 | für Mitgliederversammlungen |
12 | + Diskussion und Abstimmung von Entwürfen von |
13 | Positionspapieren |
14 | - Organisation |
15 | + Entwurf und Freigabe von Pressetexten |
16 | + Planung und Organisation von Veranstaltungen |
17 | |
18 | Ein wesentliches Merkmal von Liquid Democracy Systemen ist |
19 | unabhängig von dem einzelnen Einsatzzweck die Möglichkeit zu |
20 | Stimmdelegation: zu jedem Thema soll es einem Mitglied |
21 | möglich sein, seine Stimme auf ein anderes Mitglied zu |
22 | übertragen, wenn dieses beispielsweise in einem Themengebiet |
23 | besonders kompetent ist. |
24 | |
25 | Abhängig vom Einsatzzweck sind jedoch unterschiedliche |
26 | Datenschutzziele unterschiedlich wichtig zu bewerten. So |
27 | gibt es ohne Zweifel Szenarien, in denen eine möglichst |
28 | weitgehende Anonymisierung gewährleistet, dass sich Einzelne |
29 | unbeeinflusst von äußeren Umständen an Diskussionen zu |
30 | heiklen Themen beteiligen können. Andererseits muss es |
31 | möglich sein, Personen unterscheidbar und damit |
32 | identifizierbar zu machen, wenn man ein funktionierende |
33 | Delegationssystem anstrebt. In der Regel wird jedoch eine |
34 | zuordnung eines individuellen Nutzers innerhalb des LD |
35 | Systemes zu einer real existierenden Person nicht unbedingt |
36 | nötig sein, was die Nutzung von Pseudonymen sinnvol |
37 | erscheinen lässt. |
38 | |
39 | Ein wesentliches Datenschutzziel, dass abhängig vom |
40 | Einsatzzweck unterschiedlich bewertet werden könnte ist die |
41 | *Verfügbarkeit*. Für den Fall, dass in dem System terminlich |
42 | gebundene Entscheidungen diskutiert und abgestimmt werden |
43 | sollen, ist eine hohe Verfügbarkeit wichtig. Im Vergleich zu |
44 | anderen Aspekten scheint die Systemverfügbarkeit jedoch |
45 | zunächst eher zweitrangig einzustufen zu sein. Andererseits |
46 | würde eine niedrige Verfügbarkeit zu einer schwindenden |
47 | Nutzerakzeptanz führen. |
48 | |
49 | Die *Integrität* der Daten ist in jedem Einsatzszenario |
50 | wichtig. Jegliche Manipulationen an den Datenbeständen |
51 | würden die Glaubwürdigkeit sämtlicher Abstimmungsergebnisse |
52 | in Frage stellen und müssen deshalb mit hoher Priorotät |
53 | ausgeschlossen werden. |
54 | |
55 | Damit Nutzer das System auch bei kritischen oder kontrovers |
56 | diskutierten Fragestellungen nutzen muss ggf. ein hohes Maß |
57 | an *Vertraulichkeit* zugesichert werden. Die Identität der |
58 | Beteiligten sollte nicht angemeldeten Nutzern verborgen |
59 | bleiben. Innerhalb des Systems muss jedoch für eine |
60 | funktionierende Delegationsstruktur die Möglichkeit |
61 | bestehen, Nutzer anhand eines Pseudonyms zu identifizieren, |
62 | eine grundsätzliche Anonymität ist hier nicht sinnvoll. |
63 | Jedem Nutzer muss es aber möglich sein, sein Pseudonym zu |
64 | wechseln, wenn er dies wünscht. |
65 | |
66 | Damit Entscheidungen, die innerhalb eines Liquid Feedback |
67 | Systems nachvollziehbar sind, ist ein hohes Maß an |
68 | *Transparenz* zu gewährleisten. Während bei Wahlen aus |
69 | nachvollziehbaren Gründen die Anonymität der Wähler |
70 | absoluten Vorrang geniesst, ist bei Abstimmungen durchaus |
71 | auch wichtig, nachvollziehen zu können, wer welche Position |
72 | eingenommen hat. Einerseits wird damit das Auszählergebnis |
73 | nachvollziehbar. Andererseits wird aber nur dadurch, dass |
74 | die Beteiligung einzelner an Diskussuinne und Abstimmungen |
75 | Nachvollziehbar ist, möglich gemacht dass für Delegationen |
76 | solche Mitglieder ausgewählt werden können, die die eigene |
77 | Position gut vertreten: wenn ein Delegierter sich an einer |
78 | Debatte entgegen meinen eigenen Interessen beteiligt, muss |
79 | ich dies rechtzeitig erkennen können, um die Delegation |
80 | ggfs. zu ändern oder selbst abzustimmen. Wenn es möglich |
81 | wird, dass sich auch nur einzelne Anonym beteiligen, würde |
82 | ich nicht erkennen können, wenn mein Delegierter gegen meine |
83 | Überzeugung abstimmt. |
84 | |
85 | Sowohl bei den unmittelbar bersonenbezogenen Nutzerdaten |
86 | (Name, Kontaktdaten, etc. sofern angegeben) als auch bei |
87 | Diskussions oder Abstimmungsbeiträgen ist eine |
88 | *Intervenierbarkeit* sicherzustellen. In den verbreiteten |
89 | Tools ist es den Nutzern üblicherweise möglich, Nutzerdaten |
90 | jederzeit selbst zu aktualisieren. Üblich ist auch, das |
91 | Diskussions- und Abstimmungsbeiträge während der |
92 | entsprechenden Prozessphasen jederzeit abgeändert werden |
93 | können. Nach Abschluss der entsprechnden Phase muss aber |
94 | aufgrund der gebotenen Nachvollziehbarkeit sichergestellt |
95 | werden, dass Nachträgliche Manipulationen nicht mehr |
96 | zugelassen werden. |
97 | |
98 | Um das gebotene Schutzziel der *Nicht-Verkettbarkeit* von |
99 | Nutzerdaten zu erreichen, darf keine unmittelbare |
100 | Verknüpfung von Nutzeraccounts in einem Liquid Feedback |
101 | System und den registrierten Mitgliederdaten innerhalb der |
102 | Mitgliederdatenbank bzw. den realen Personen hergestellt |
103 | werden. Die Nutzung einer "Clearing-Stelle" scheint eine |
104 | geeignete Lösung zu sein, um andererseits sicherzustellen, |
105 | das jedes Mitglied im Liquid Democracy System nur mit einem |
106 | einzigen Account zur Zeit zugreifen kann. |
Der Text verglichen mit der Originalversion
1 | |
2 | man sich Gedanken dazu machen, wie und wofür das Tool |
3 | genutzt werden soll und welche Anforderungen an den |
4 | Datenschutz sich daraus ergeben. |
5 | |
6 | Für den Einsatz eines Liquid Democracy Tools im |
7 | Landesverband Schleswig-Holstein können sich ganz |
8 | unterschiedliche Nutzungsszenarien ergeben. Beispiele sind: |
9 | - Politische Willensbildung |
10 | + Diskussion und Abstimmung von Entwürfen von |
11 | Antragstexten für Mitgliederversammlungen |
12 | + Diskussion und Abstimmung von Entwürfen von |
13 | Positionspapieren |
14 | - Organisation |
15 | + Entwurf und Freigabe von Pressetexten |
16 | + Planung und Organisation von Veranstaltungen |
17 | |
18 | Ein wesentliches Merkmal von Liquid Democracy Systemen ist |
19 | |
20 | Möglichkeit zu Stimmdelegation: zu jedem Thema soll es |
21 | einem Mitglied möglich sein, seine Stimme auf ein anderes |
22 | Mitglied zu übertragen, wenn dieses beispielsweise in einem |
23 | Themengebiet besonders kompetent ist. |
24 | |
25 | Abhängig vom Einsatzzweck sind jedoch unterschiedliche |
26 | Datenschutzziele unterschiedlich wichtig zu bewerten. So |
27 | gibt es ohne Zweifel Szenarien, in denen eine möglichst |
28 | weitgehende Anonymisierung gewährleistet, dass sich |
29 | Einzelne unbeeinflusst von äußeren Umständen an |
30 | Diskussionen zu heiklen Themen beteiligen können. |
31 | Andererseits muss es möglich sein, Personen unterscheidbar |
32 | und damit identifizierbar zu machen, wenn man ein |
33 | funktionierende Delegationssystem anstrebt. In der Regel |
34 | wird jedoch eine zuordnung eines individuellen Nutzers |
35 | innerhalb des LD Systemes zu einer real existierenden |
36 | Person nicht unbedingt nötig sein, was die Nutzung von |
37 | Pseudonymen sinnvol erscheinen lässt. |
38 | |
39 | Ein wesentliches Datenschutzziel, dass abhängig vom |
40 | Einsatzzweck unterschiedlich bewertet werden könnte ist die |
41 | *Verfügbarkeit*. Für den Fall, dass in dem System |
42 | terminlich gebundene Entscheidungen diskutiert und |
43 | abgestimmt werden sollen, ist eine hohe Verfügbarkeit |
44 | wichtig. Im Vergleich zu anderen Aspekten scheint die |
45 | Systemverfügbarkeit jedoch zunächst eher zweitrangig |
46 | einzustufen zu sein. Andererseits würde eine niedrige |
47 | Verfügbarkeit zu einer schwindenden Nutzerakzeptanz führen. |
48 | |
49 | Die *Integrität* der Daten ist in jedem Einsatzszenario |
50 | wichtig. Jegliche Manipulationen an den Datenbeständen |
51 | würden die Glaubwürdigkeit sämtlicher Abstimmungsergebnisse |
52 | in Frage stellen und müssen deshalb mit hoher Priorotät |
53 | ausgeschlossen werden. |
54 | |
55 | Damit Nutzer das System auch bei kritischen oder kontrovers |
56 | diskutierten Fragestellungen nutzen muss ggf. ein hohes Maß |
57 | an *Vertraulichkeit* zugesichert werden. Die Identität der |
58 | Beteiligten sollte nicht angemeldeten Nutzern verborgen |
59 | bleiben. Innerhalb des Systems muss jedoch für eine |
60 | funktionierende Delegationsstruktur die Möglichkeit |
61 | bestehen, Nutzer anhand eines Pseudonyms zu identifizieren, |
62 | eine grundsätzliche Anonymität ist hier nicht sinnvoll. |
63 | Jedem Nutzer muss es aber möglich sein, sein Pseudonym zu |
64 | wechseln, wenn er dies wünscht. |
65 | |
66 | Damit Entscheidungen, die innerhalb eines Liquid Feedback |
67 | Systems nachvollziehbar sind, ist ein hohes Maß an |
68 | *Transparenz* zu gewährleisten. Während bei Wahlen aus |
69 | nachvollziehbaren Gründen die Anonymität der Wähler |
70 | absoluten Vorrang geniesst, ist bei Abstimmungen durchaus |
71 | auch wichtig, nachvollziehen zu können, wer welche Position |
72 | eingenommen hat. Einerseits wird damit das Auszählergebnis |
73 | nachvollziehbar. Andererseits wird aber nur |
74 | |
75 | an Diskussuinne und Abstimmungen Nachvollziehbar ist, |
76 | möglich gemacht dass für Delegationen solche Mitglieder |
77 | ausgewählt werden können, die die eigene Position gut |
78 | vertreten: wenn ein Delegierter sich an einer Debatte |
79 | entgegen meinen eigenen Interessen beteiligt, muss ich dies |
80 | rechtzeitig erkennen können, um die Delegation ggfs. zu |
81 | ändern oder selbst abzustimmen. Wenn es möglich wird, dass |
82 | sich auch nur einzelne Anonym beteiligen, würde ich nicht |
83 | erkennen können, wenn mein Delegierter gegen meine |
84 | Überzeugung abstimmt. |
85 | |
86 | Sowohl bei den unmittelbar bersonenbezogenen Nutzerdaten |
87 | (Name, Kontaktdaten, etc. sofern angegeben) als auch bei |
88 | Diskussions oder Abstimmungsbeiträgen ist eine |
89 | *Intervenierbarkeit* sicherzustellen. In den verbreiteten |
90 | Tools ist es den Nutzern üblicherweise möglich, Nutzerdaten |
91 | jederzeit selbst zu aktualisieren. Üblich ist auch, das |
92 | Diskussions- und Abstimmungsbeiträge während der |
93 | entsprechenden Prozessphasen jederzeit abgeändert werden |
94 | können. Nach Abschluss der entsprechnden Phase muss aber |
95 | aufgrund der gebotenen Nachvollziehbarkeit sichergestellt |
96 | werden, dass Nachträgliche Manipulationen nicht mehr |
97 | zugelassen werden. |
98 | |
99 | Um das gebotene Schutzziel der *Nicht-Verkettbarkeit* von |
100 | Nutzerdaten zu erreichen, darf keine unmittelbare |
101 | Verknüpfung von Nutzeraccounts in einem Liquid Feedback |
102 | System und den registrierten Mitgliederdaten innerhalb der |
103 | Mitgliederdatenbank bzw. den realen Personen hergestellt |
104 | werden. Die Nutzung einer "Clearing-Stelle" scheint eine |
105 | geeignete Lösung zu sein, um andererseits sicherzustellen, |
106 | das jedes Mitglied im |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | Zeit zugreifen kann. |
126 |
-
Bewerten Sie die Original- und die eingebrachten Versionen eines Beschlusses, indem Sie über die Pfeile Ihre Zustimmung (hoch) oder Ablehnung (runter) ausdrücken. Sie können dabei auch mehreren Versionen zustimmen oder diese ablehnen.
-
Wählen Sie, ob Änderungen im Vergleich zur Originalversion hervorgehoben werden sollen.
-
Sie können hier auch eine neue Version des Beschlusses einbringen.
Vorschlag
Nutzungs- und Datenschutzziele
Definition von Nutzungs- und Datenschutzzielen